I. Field of the Invention
This invention relates generally to database technology, and more specifically, to a computer system for providing access to a database upon a request from an application computer program.
II. Background of the Invention
Conventional database systems typically process two types of information, i.e., the actual data and the information describing the data (the meta-data). The meta-data is typically referred to as the data model and may be viewed as structural information, i.e., a description of how the actual data is to be structured.
FIG. 1 depicts a conventional database system. The database as shown in FIG. 1 includes interpreting database runtime module and storage engine 110, data storage 120, online data dictionary 130, schema compiler 140, application program 150, and schema/data model 160. Interpreting database runtime module and storage engine 110 (or database kernel 110) serves as a database runtime storage engine, which functions as the actual data interpreter. Data storage 120 physically stores the data, i.e., data files. Usually, data storage 120 uses the operating system's standard file system, but may have special file access in order to speed up data transfer to and from a disk. Usually, the data storage is platform dependent, where data stored on one platform cannot be transferred to another platform without data conversion.
Online dictionary 130 stores the meta-data. Meta-data may include information describing tables, columns, fields, data types for columns, and domain restrictions for these columns. For example, online dictionary 130 may include information such as: NAME is a character string consisting of characters ‘a’-‘z’, ‘A’-‘Z’, and ‘.’, ‘ ’, ‘_’; INCOME is a positive integer; CURRENCY is one of ‘USD’, ‘NOK’, ‘EUR’, ‘JPY’, ‘SEK’, ‘DKK’, etc. Online dictionary 130 also stores information about the different constraint types as primary keys, foreign keys, subset constraints, exclude constraints, etc. However, conventional database systems only handle primary keys, unique keys, foreign keys, and mandatory columns. Additionally, information about external views are stored, i.e., how the information is to be presented in a specific application. For example, in one application only the “Name” and “Address” columns of the table “Person” may be viewed, while in another application, “Project”, “Assignment” and “Person” tables may be viewed in a compound table “Project-Assignment”. Additionally, many data dictionaries also contain user definitions and user authorization information.
Interpreting database runtime module and storage engine 110 is the heart of the database system and handles data retrieval and update requests. In order to fulfill a request, the interpreting database runtime module and storage engine 110 must consult with online data dictionary 130 in order to validate the application's request. The interpreting database runtime module and storage engine 110 checks if the requested data is known, or should be know, by application program 150, and performs a mapping to the underlying data model. The online data dictionary is then consulted in order to determine how the actual request to the storage engine should be expressed. When the result from the storage engine is returned, the interpreting database runtime module and storage engine 110 has to again consult the online data dictionary 130 in order to perform a transformation of the retrieved data to fit the applications expectations with respect to naming and structure.
If the application program 150 wants to update the database by either inserting new data or deleting or updating existing data, the interpreting database runtime module and storage engine 110 performs a consistency check of the database based on the rules stored in the online data dictionary 130. For each rule in the online data dictionary 130, the interpreting database runtime module and storage engine 110 has to analyze the rule and perform a consistency check. This is very complicated and time consuming. Conventional database systems perform this type of consistency control after every update to prevent a large backlog of consistency controls needing to be performed. If the controls were carried out immediately, the functionality required to perform the control after the entire transaction has been carried out would be very complex. As a result, conventional the interpreting database runtime module and storage engines 110 are oversized which creates inefficiency.
The schema compiler 140 checks the data model for consistency. If the data model is consistent it stores the data model information in the data dictionary. If a customer has only has a runtime version of the database system, the schema compiler 140 is left out. The ability to make changes to the data model is then efficiently removed (Create Table, Alter Table and Drop Table will not work). Additionally, in current SQL databases, the schema compiler is accessible from most applications (including user-developed applications).
Further, in conventional database systems, when an application issues an update or retrieval request to the database system, the interpreting database runtime module and storage engine 110 has to dynamically validate the request and dynamically create an execution plan. In performing these tasks, the system has to send many inquiries to the data dictionary 130 and interpret the results. This has to be done for every single request. Any inquiry to the data dictionary 130 decreases performance significantly. It also requires the interpreting database runtime module and storage engine 110 to be constructed such that all types of data models can be handled. As a result, there is a lot more program code than necessary for most data models. Further, the interpreting database runtime module and storage engine 110 is oversized for most applications.
Thus, in order to handle all types of data models, including a complete set of integrity enforcement rules and proper transaction handling in conjunction with the constraints, the complexity of such an interpreting database runtime module and storage engine 110 will increase tremendously and the performance will drop catastrophically. Therefore, current interpreting database runtime module and storage engine 110 only handle a small portion of possible data models, they only offer a limited set of constraint mechanisms, they offer a limited transaction model and finally they suffer from poor performance and oversized executables.
As such, there is a need for a database system that reduces computing power requirements and for facilitating database and application programming to ease constraint handling and thereby reduce application complexity.